Amazon PinpointのSMSシミュレーターを使って、SMS送信の成功/失敗のイベントレコードを観察する
いわさです。
Amazon PinpointではSMS送信を行うことが出来ますが、送信要件は国ごとに規制が多く、どの機能が使えてどの機能が使えないなど多岐に渡ります。
詳細は以下に表形式でまとまっているのですが、Pinpointには送信先のシミュレーションを行うための電話番号がいくつか用意されています。
本日は、これらを使ってSMS送信したときの挙動を観察してみましたのでPinpointにおけるイベントの確認方法とあわせて紹介します。
SMSシミュレーター
25カ国×2イベントの50個の電話番号が用意されています。
今回はここから以下の2つを試してみました。
国 | イベント | 電話番号 |
---|---|---|
オーストラリア | 成功 | +61455944038 |
オーストラリア | 失敗 | +61455944039 |
厳密にいえばアメリカの成功イベント+14254147755
も試してみたのですが、なぜか失敗しました。
送信元電話番号はアメリカとカナダの2つ用意していたのですが、要件によって送れない場合があるという情報は見たので、今回はあまり深追いせずに送信に成功するオーストラリアの2件を使用することにしました。
テスト送信
Pinpointのテスト送信機能を使って、簡単に送信を試すことが出来ますので早速試してみます。
まずは成功イベントの電話番号で送信します。
期待どおり成功しました!
次に失敗イベントの電話番号で送信します。
コンソール上は成功で表示されていますね。
イベントストリームを設定し、イベントレコードを確認する
APIの結果のみで判断するのではなく、SMSイベントについてはPinpointイベントを監視するようガイドラインがあります。
PinpointではイベントストリームにKinesis Data Stream/Kinesis Data Firehoseに送信出来るので、今回はFirehoseからS3へ出力しイベントレコードを確認してみたいと思います。
イベントストリームの設定画面では、SNSの記載がありますが、選択出来ないのとドキュメントにも一切記載がないので表記誤りの可能性が高いです。
ただ、UIからすると他のストリームサービスの選択も想定されているような気がしますね。アップデートを注視したいと思います。
設定出来たら、先程と同じようにテスト送信してみます。
イベントレコード
ストリーム配信先に指定したS3バケットのイベントレコードを確認してみましょう。
成功イベント
成功イベントのレコードはイベントタイプが_SMS.SUCCESS
ですね。
ちなみに、_
で始まるイベントはAWSの管理イベントを指しています。
{ "event_type": "_SMS.SUCCESS", "event_timestamp": 1640333800731, "arrival_timestamp": 1640333800952, "event_version": "3.1", "application": { "app_id": "67f44a342db2459f857e23ba106e95f1", "sdk": {} }, "client": { "client_id": "erlu7sc+hui+bq0wk4sbutxvche" }, "device": { "platform": {} }, "session": {}, "attributes": { "sender_request_id": "v5btli6d01t5o2pve97v5or1pq67s2s5kfg7lto0", "destination_phone_number": "+61455944038", "iso_country_code": "AU", "record_status": "SUCCESSFUL", "mcc_mnc": "nullnull", "number_of_message_parts": "1", "message_id": "v5btli6d01t5o2pve97v5or1pq67s2s5kfg7lto0", "message_type": "Transactional", "origination_phone_number": "aaaa" }, "metrics": { "price_in_millicents_usd": 3450.0 }, "awsAccountId": "123456789012" }
失敗イベント
次に失敗イベントを確認してみます。
コンソール上は成功の表示でしたが、失敗イベントの場合は以下のようにしっかりFAILURE
イベントが発生していました。
{ "event_type": "_SMS.FAILURE", "event_timestamp": 1640334287232, "arrival_timestamp": 1640334287472, "event_version": "3.1", "application": { "app_id": "67f44a342db2459f857e23ba106e95f1", "sdk": {} }, "client": { "client_id": "gmhwtppkhp1szz2dldu6w++wxum" }, "device": { "platform": {} }, "session": {}, "attributes": { "sender_request_id": "qslbqg2c402h5ps4ck3ebm2qumvrv9ejdckb5180", "destination_phone_number": "+61455944039", "iso_country_code": "AU", "record_status": "BLOCKED", "mcc_mnc": "nullnull", "number_of_message_parts": "1", "message_id": "qslbqg2c402h5ps4ck3ebm2qumvrv9ejdckb5180", "message_type": "Transactional", "origination_phone_number": "aaaa" }, "metrics": { "price_in_millicents_usd": 3450.0 }, "awsAccountId": "123456789012" }
record_status
がBLOCKED
ですね。
ここは失敗した理由に応じて様々なステータスが設定されます。
record_status | 詳細 |
---|---|
SUCCESSFUL | メッセージがキャリアによって受け入れられました。 |
DELIVERED | メッセージが受信者のデバイスに配信されました。 |
PENDING | メッセージはまだ受信者のデバイスに配信されていません。 |
INVALID | 送信先の電話番号が無効です。 |
UNREACHABLE | 受信者のデバイスが現在到達できないか、利用できません。たとえば、デバイスの電源がオフになっているか、ネットワークから切断されている可能性があります。後でメッセージの送信を再試行できます。 |
UNKNOWN | メッセージの配信を妨げるエラーが発生しました。このエラーは通常一時的なものであるため、後でもう一度メッセージを送信できます。 |
BLOCKED | 受信者のデバイスが発信元番号からの SMS メッセージをブロックしています。 |
CARRIER_UNREACHABLE | 受信者のモバイルネットワークの問題により、メッセージを配信できませんでした。このエラーは通常一時的なものであるため、後でもう一度メッセージを送信できます。 |
SPAM | 受信者のモバイルキャリアがメッセージの内容をスパムとして識別し、メッセージの配信をブロックしました。 |
INVALID_MESSAGE | SMS メッセージの本文が無効であるため、配信できません。 |
CARRIER_BLOCKED | 受信者のキャリアがこのメッセージの配信をブロックしています。これは、多くの場合、キャリアがメッセージの内容を未承諾または悪意のあるものとして識別した場合に発生します。 |
TTL_EXPIRED | 特定の期間内に SMS メッセージを配信できませんでした。このエラーは通常一時的なものであるため、後でもう一度メッセージを送信できます。 |
MAX_PRICE_EXCEEDED | アカウントの月額の SMS 使用制限を超過 |
驚きました。SMS送信イベントでここまで細かいエラー情報を取得出来たとは。
Pinpointとしては送信エラー時の対応や分析が出来るようにステータスが用意されている形ですね。
通信キャリアに依存していそうな気もするので環境毎の十分なテストが必要という前提ですが、期待どおりエラーを受け取れるようであればEメールのバウンス管理に似た運用がSMSでも可能になりそうですね。
さいごに
本日はPinpontのSMSシミュレーターを使ってみました。
その中でイベントストリームの使い方と、SMSイベントのデータ構造を紹介しました。
トランザクションからプロモーションまで、様々なパターンでSMS送信が考えられますが、送信して終わりではなく、イベントストリームでしっかりと配信状況を確認出来るとシステム改善にいかせそうですね。
他のサービスのログと同じように、Firehoseから簡単にS3へ出力が出来るので、分析基盤へのインプットにも良いですね。